home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / Games / ms-0.07 / TO_DO < prev   
Encoding:
Text File  |  1995-06-27  |  4.7 KB  |  100 lines
  1. This file contains some random notes about things that could be done
  2. to improve MandelSpawn.  Feel free to try you hand at any of these and
  3. send me context diffs; if your enhancements are nice and clean I will
  4. incorporate them into the distribution.  If you make a significant
  5. contribution (more than just a few lines of code), a written copyright
  6. disclaimer may be needed (see the end of the file COPYING).
  7.  
  8.  
  9.                     Andreas, gson@niksula.hut.fi
  10. --
  11.  
  12. The documentation needs work.  More info is needed about how to
  13. install on hosts running SunOS and/or YP/NIS. The xms(1) man
  14. page should have a RESOURCES section.  Perhaps there should be a
  15. tutorial in Texinfo format.
  16.  
  17. Add support for other visual types besides PseudoColor and StaticGray
  18. to xms, and improve the support for StaticGray visuals so that it uses
  19. greyscale instad of black-and-white if possible.
  20.  
  21. Use getservent()?
  22.  
  23. Invent a clever algorithm to decide which bitplanes to invert (instead
  24. of inverting them all) to maximize contrast when drawing the
  25. rubberband box in xms.
  26.  
  27. The "-greyscale" option of xms should not be necessary when it is
  28. possible to detect automatically that a greyscale display is being
  29. used (unfortunately some machines lie about this).
  30.  
  31. There should be a way to "loop" only part of the spectrum instead of
  32. the whole spectrum when the number of colours is smaller than the
  33. iteration count.  E.g., xms -spectrum "white-(red-blue-green)-black"
  34. would show a white exterior, black interior and repeat the
  35. red-blue-green sequence as many times as needed.
  36.  
  37. Write a widget for interactive editing of the colourmap ("spectroscope
  38. widget"?) for xms.  It could show the spectrum as a band of colours
  39. with lines marking the interpolation points, allowing the user to grab
  40. the points with the mouse and move them towards either end of the
  41. spectrum, and popping up a set of scrollbars next to the line for
  42. editing the RGB value.
  43.  
  44. A lot of identical small structures are malloc'ed and freed;
  45. it would probably be faster to put them on a linked list instead
  46. of freeing them and then allocate from that list whenever an object
  47. of the same size is needed again and the list is nonempty.
  48.  
  49. XtInitialize should not be used (in main.c), it's obsolete.
  50.  
  51. Add special-case support for more display types (those that
  52. cause the dreaded "drawing a pixel at a time, this will be very
  53. slow" message).
  54.  
  55. Add fixed-point support for other cpus (NS32K... ?) wherever
  56. it is faster than floating point. 
  57.  
  58. Add an option to mslaved to make it discard requests from outside the
  59. local network, to avoid people abusing servers at remote sites.
  60. ("netmask-style"?).
  61.  
  62. It should be possible to query the computation servers for performance
  63. statistics.  This of course turns MandelSpawn into Yet Another Unix
  64. Benchmark, and gives yet another definition of the dreaded MIPS
  65. rating: MIPS is short for "Mandelbrot Iterations Per Second" :-).  It
  66. may become a very popular benchmark because it gives very high
  67. MIPS ratings :-) :-).
  68.  
  69. Improve the protocol.  Currently the servers are idle during the
  70. round-trip to the client when they have finished one chunk and are
  71. waiting for the next.  Instead the client could send, say, two chunks
  72. initially and the server would try to maintain a queue of work to be
  73. done containing about two chunks at all times.  When sending results
  74. to a client the server should indicate how many more chunks it needs
  75. to keep the queue full.  This would also make it possible to have a
  76. single server running on a multiprocessor machine; it would then ask
  77. for at least as many chunks as there are CPUs in the machine.  Note
  78. that the "queue" of work to be done probably ought to be a LIFO
  79. structure so that the most recent requests are served first; they are
  80. the ones that are most likely to be finished before the client has
  81. retransmitted the same chunk to another server.  Having most chunks
  82. calculated immediately and a few chunks very late is better than
  83. delaying all chunks uniformly as when using a FIFO.
  84.  
  85. There should also be an "abort" packet that is sent to all computation
  86. servers when an update has finished, so that they don't continue
  87. making calculations whose results will never be used.  Note that this
  88. will also reduce network load because the abort packet is smaller than
  89. the packet whose transmission it inhibits.
  90.  
  91. Implement multiple-precision fixed-point arithmetic.  Note that even
  92. a 64-bit fixed-point number will have more precision than the mantissa
  93. of a typical C "double", so the client will also have to do its
  94. coordinate manipulations (zooming, etc.) using the fixed-point routines
  95. or some other more or less portable, multiple-precision arithmetic
  96. package.  The GNU mp library could be useful here.
  97.  
  98. There should be a way to scroll the image inside an xms window,
  99. recalculating only the newly exposed areas at the trailing edge.
  100.